[test-84/e2e] E2E 테스트 안정화 및 회귀 수정 - #216

Summary

같은 커밋으로 CI를 20회 반복 실행해 E2E 16건의 케이스별 실패율을 측정했습니다.
측정 결과를 근거로 CI의 retries를 2회에서 1회로 정했습니다.
측정 전용으로 넣었던 설정은 모두 되돌렸습니다.
Closes #215

Why

왜 이 작업을 진행했나요?

CI의 retries가 2회로 되어 있었는데 관측 없이 정한 값이었습니다. 케이스별 실패율을 모르니 2회가 적절한지 판단할 근거가 없었습니다.

재시도 횟수는 두 방향으로 손해를 냅니다. 너무 적으면 일회성 오류가 실패로 남고, 너무 많으면 진짜 회귀의 실패 확정이 늦어집니다. 그래서 값을 정하기 전에 실제 흔들림 크기를 먼저 재기로 했습니다.

Decision

어떤 구현 방식을 선택했나요?

retries: process.env.CI ? 1 : 0으로 정했습니다. 로컬은 기존과 같이 0회이며 실행 방식을 바꾸지 않습니다.

측정은 이 PR의 실행을 gh run rerun으로 반복했습니다. 재실행은 커밋 SHA가 그대로라 같은 커밋 조건을 정확히 만족합니다. develop에 트리거를 추가하지 않아도 됩니다.

• 대상 커밋: 49c01fb
• 워크플로 실행: run 33605863639, attempt 1~20
• 뷰포트: mobile. base가 develop이라 matrix가 mobile 단일로 분기합니다
• 실행 시각: attempt 118은 2026-09-02 07:5309:03 UTC, attempt 1920은 2026-09-03 01:1401:17 UTC

집계는 각 attempt의 job 로그에서 가져왔습니다. 전체 재실행은 이전 attempt의 아티팩트를 지우므로 json reporter 파일은 마지막 attempt 것만 남습니다. attempt별 로그는 그대로 남아 있어 이쪽으로 집계했습니다.

실행 단위 측정 결과

케이스별 실패율

#209에서 확인했던 테스트 계정 tag 충돌은 20회 동안 한 번도 재현되지 않았습니다. 3dc3ada의 재시도 처리가 동작하는 것으로 보입니다.

1회로 정한 이유

• 케이스 실패율 0.31%짜리 일회성 오류는 한 번의 재시도로 걸러집니다.
• 반복해서 깨지는 테스트는 그대로 실패로 남습니다.
• 기존 값 2회는 관측된 흔들림 크기에 비해 과하고, 진짜 회귀의 실패 확정만 늦춥니다.

검토한 대안

Changes

무엇이 변경되었나요?

Fix

• playwright.config.ts의 retries를 process.env.CI ? 1 : 0으로 바꿨습니다. CI가 2회에서 1회가 됩니다.

Test

• 측정 전용으로 넣었던 retries: 0과 json reporter, 산출물 업로드 if: always()를 모두 되돌렸습니다.

Trade-off

한계와 트레이드오프

• 재시도로 통과한 건은 Playwright가 flaky로 따로 집계하므로 관측은 계속됩니다. PGRST303이 flaky로 반복해서 뜨면 그때 근거를 갖고 seeder 재시도를 넣습니다.
• attempt 19의 trace와 스크린샷은 남아 있지 않습니다. 전체 재실행이 이전 attempt의 아티팩트를 지웠기 때문입니다. 원인 판단은 job 로그만 근거로 합니다.
• PC 뷰포트 matrix는 이번에 확인하지 못했습니다. 이 PR은 base가 develop이라 matrix가 mobile 단일로 분기합니다. main 대상 PR에서만 확인할 수 있어 다음 릴리즈 PR에서 봐야 합니다.

Impact

기존 기능에 미치는 영향

• develop 대비 남는 변경은 playwright.config.ts의 한 줄입니다.
• CI에서 재시도가 한 번으로 줄어듭니다. 두 번 이상 깨지던 테스트는 이제 실패로 확정됩니다.
• 로컬 실행은 바뀌지 않습니다.
• 제품 코드 변경은 없습니다.

Edge Cases

Edge Case 및 실패 시나리오

attempt 19에서 케이스 하나가 실패했습니다.

1) [mobile] › e2e/auth.spec.ts:23:7 › 로그인 콜백 처리 › 약관에 동의한 사용자는 인증 콜백 뒤 요청한 초대 경로로 이동한다

    {
      code: 'PGRST303',
      details: null,
      hint: null,
      message: 'JWT issued at future'
    }

PostgREST가 요청에 담긴 토큰의 iat를 자기 시계보다 미래로 판단해 거절했습니다.

실패 지점은 브라우저가 아니라 테스트 준비 단계의 Node 코드입니다. 오류 출력에 stack이 없다는 것은 Error가 아닌 plain object가 던져졌다는 뜻이고, supabase-js의 PostgrestError가 그 형태입니다. e2e/fixtures/seed.ts에서 this.admin으로 PostgREST를 호출한 뒤 throw error 하는 지점들이 여기 해당합니다.

그래서 createSession이 만드는 사용자 세션 토큰과는 무관합니다. 토큰을 발급하고 iat를 검증하는 일은 모두 Supabase에서 일어나며 우리 코드는 이 시각에 관여하지 않습니다. 원인을 환경으로 분류했습니다. 같은 커밋의 다른 19회에서는 재현되지 않았습니다.

retries가 이 실패 유형을 걸러냅니다. 재시도는 fixture teardown을 attempt마다 실행하므로 잔여 데이터도 남지 않습니다.

Review Points

리뷰어가 집중해서 봐야 할 부분

🔴 High

• retries를 1회로 정한 판단을 확인해 주세요. 케이스 단위 실패율 0.31%를 근거로 삼았습니다.

🟡 Medium

• PGRST303을 코드로 대응하지 않고 재시도로 넘긴 결정을 확인해 주세요. 320회 중 1회이고 원인이 Supabase에 있어 지금은 근거가 약하다고 판단했습니다.

🟢 Low

• 측정 전용 설정이 모두 되돌아갔는지 확인해 주세요.

Validation

어떻게 검증했나요?

• 단위 테스트
• E2E 테스트
• 수동 테스트
• lint
• typecheck

실행 결과

• 같은 커밋으로 20회 반복 실행했습니다. 실행 19회 성공, 1회 실패입니다. 케이스 단위로는 320회 중 1회 실패입니다.
• 산출물 업로드를 확인했습니다. attempt 20에서 playwright-mobile-20 아티팩트가 성공 실행에도 올라왔고, 실패 시 업로드는 attempt 19에서 동작을 확인했습니다.